真正危險的漏洞，往往不是你寫的，而是你「下載的」。

前言

在我當網路工程師時，最常做的就是 追補丁：一旦有新的漏洞公告，就得趕緊修正，免得被攻破。這件事聽起來很瑣碎，但誰都知道——只要一個漏洞沒補上，就可能成為災難的缺口。

進到 DevSecOps 領域後，問題並沒有消失，只是換了場景。
這次的敵人不是我自己寫的程式碼，而是我「請進城牆」的第三方套件。

在 Python 的世界裡，我們動不動就 pip install 幾十個套件，這些套件有些是幫手，有些卻可能藏著漏洞。就像城牆裡混進臥底巨人，一旦爆發，破壞力比牆上的裂縫還要可怕。

何況現在有許多人都透過 Chatgpt 來生成程式碼，可能無意間就使用到不存在於 pip 的套件。

這就是 pip-audit 登場的理由：它能比對專案依賴和漏洞資料庫，快速揪出「不該留在城牆內」的套件，成為 DevSecOps pipeline 裡的第二道防線。

1. 為什麼需要依賴安全檢查？

•	套件是最大攻擊面：專案自己寫的程式碼可能只有幾千行，但套件加起來卻是幾十萬行。
•	漏洞資訊量龐大：每天都有新的 CVE，人工追蹤根本不可能。
•	合規與審計：在某些產業，你必須能證明「所有依賴都有檢查紀錄」。

換句話說：第一道防線（程式碼檢查）守住牆面，第二道防線（依賴檢查）則要確保城內沒臥底。

2. pip-audit 入門

安裝：

pip install pip-audit

掃描專案依賴：

pip-audit

範例輸出：

Found 1 known vulnerability in 1 package
Name     Version  ID             Fix Versions
flask    1.1.2    PYSEC-2021-123  1.1.3

這告訴你：
• flask==1.1.2 有已知漏洞
• 漏洞編號：PYSEC-2021-123
• 修復方式：升級到 1.1.3

高危漏洞就像臥底巨人已經露餡，必須立刻處理。低危漏洞則可以排進技術債清單，但必須記錄在案，不能裝沒看見。

3. 與 CI/CD 整合

在 .github/workflows/ci.yml 裡加一個 step：

- name: Dependency audit
  run: pip-audit -r requirements.txt

如果還有 requirements-dev.txt，建議也一起檢查：

- name: Dependency audit (dev)
  run: pip-audit -r requirements-dev.txt

這樣，每次有人 push 或發 PR，pipeline 就會自動巡查一遍，防止臥底混進主分支。

要不要讓 CI 掃到漏洞就 fail？
建議分階段：
• 初期：只報告不阻擋，先建立健康度基線。
• 穩定後：設定「高危漏洞 → fail」，中低危漏洞則允許合併，但要追蹤 issue。
這樣既能保護專案，又不會讓開發流程突然陷入「全員被卡死」的窘境。

在 DevSecOps 的基礎安全檢查裡，有兩道互補的防線：
• Bandit (SAST) → 防止「自己挖牆角」，檢查程式碼裡的危險寫法。
• pip-audit (Dependency Scanning) → 防止「臥底混進城」，檢查外部套件的已知漏洞。

兩者合起來，才能讓城牆內外都保持安全。

4. 總結

今天我們把 DevSecOps 的安全檢查從程式碼，延伸到依賴套件。
• pip-audit 就像巡邏兵，專門揪出混在牆內的臥底巨人。
• 它能掃描 requirements.txt，並比對漏洞資料庫，指出危險版本。
• 與 CI/CD 整合後，能確保每一次提交都經過依賴安全檢查。

過去我在當網路工程師時，漏洞要靠人工追補丁，總是慢半拍。
現在透過 DevSecOps，把這工作自動化，讓 pipeline 成為第二道防線，隨時巡邏。

Bandit 守住程式碼，pip-audit 守住套件依賴。
一內一外，才能確保城牆不會因為臥底而崩壞。